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Abstract 

Mobile  is  an  extension  of  the  .NET  Common  Intermediate  Lan¬ 
guage  that  supports  certified  In-Lined  Reference  Monitoring. 
Mobile  programs  have  the  useful  property  that  if  they  are  well- 
typed  with  respect  to  a  declared  security  policy,  then  they  are 
guaranteed  not  to  violate  that  security  policy  when  executed. 
Thus,  when  an  In-Lined  Reference  Monitor  (IRM)  is  expressed 
in  Mobile,  it  can  be  certified  by  a  simple  type-checker  to  eliminate 
the  need  to  trust  the  producer  of  the  IRM. 

Security  policies  in  Mobile  are  declarative,  can  involve  un¬ 
bounded  collections  of  objects  allocated  at  runtime,  and  can  re¬ 
gard  infinite-length  histories  of  security  events  exhibited  by  those 
objects.  The  prototype  Mobile  implementation  enforces  proper¬ 
ties  expressed  by  finite-state  security  automata — one  automaton 
for  each  security-relevant  object — and  can  type-check  Mobile  pro¬ 
grams  in  the  presence  of  exceptions,  finalizers,  concurrency,  and 
non-termination.  Executing  Mobile  programs  requires  no  change 
to  existing  .NET  virtual  machine  implementations,  since  Mobile 
programs  consist  of  normal  managed  CIL  code  with  extra  typing 
annotations  stored  in  .NET  attributes. 

Categories  and  Subject  Descriptors  D.L2  [Programming  Tech¬ 
niques]'.  Automatic  Programming;  D.2.1  [Software  Engineer¬ 
ing]'.  Requirements/Specifications;  D.4.6  [Operating  Systems]'. 
Security  and  Protection — Access  controls;  F.3.1  [Logics  and 
Meanings  of  Programs]'.  Specifying  and  Verifying  and  Reasoning 
about  Programs — Specification  techniques;  K.6.5  [Management 
of  Computing  and  Information  Systems] :  Security  and  Protection 

General  Terms  Security 
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1.  Introduction 

Language-based  approaches  to  computer  security  have  employed 
two  major  strategies  for  enforcing  security  policies  over  untrusted 
programs. 

•  Low-level  type  systems,  such  as  those  used  in  Java  bytecode 
HD,  .NET  CIL  O,  and  TAL  for  x86  1231.  can  enforce  im¬ 
portant  program  invariants  such  as  memory  safety  and  con¬ 
trol  safety,  which  dictate  that  programs  must  access  and  trans¬ 
fer  control  only  to  certain  suitable  memory  addresses  through¬ 
out  their  executions.  Proof-Carrying  Code  (PCC)  (H  general¬ 
izes  the  type-safety  approach  by  providing  an  explicit  proof  of 
safety  in  first-order  logic. 

•  Execution  Monitoring  technologies  such  as  Java  and  .NET  stack 
inspection  (Ml  dD  11.22.1 1],  SASI  dD,  Java-MAC  (20l,  Java- 
MOP  (D,  Polymer  (D,  and  Naccio  da,  use  runtime  checks 
to  enforce  temporal  properties  that  can  depend  on  the  history 
of  the  program’s  execution.  Eor  example,  SASI  Java  was  used 
to  enforce  the  policy  that  no  program  may  access  the  network 
after  it  reads  from  a  file  da.  For  efficiency,  execution  monitors 
are  often  implemented  as  In-lined  Reference  Monitors  (IRM’s) 
(m.  wherein  the  runtime  checks  are  in-lined  into  the  untrusted 
program  itself  to  produce  a  self-monitoring  program. 

The  IRM  approach  is  capable  of  enforcing  a  large  class  of  pow¬ 
erful  security  policies,  including  ones  that  cannot  be  enforced  with 
purely  static  type-checking  d3.  In  addition,  IRM’s  can  enforce 
a  flexible  range  of  policies,  often  allowing  the  code  recipient  to 
choose  the  security  policy  after  the  code  is  received,  whereas  static 
type  systems  and  PCC  usually  enforce  fixed  security  policies  that 
are  encoded  into  the  type  system  or  proof  logic  itself,  and  that  there¬ 
fore  cannot  be  changed  without  changing  the  type  system  or  certi¬ 
fying  compiler. 

But  despite  their  power  and  flexibility,  the  rewriters  that  au¬ 
tomatically  embed  IRM’s  into  untrusted  programs  are  typically 
trusted  components  of  the  system.  Since  rewriters  tend  to  be  large 
and  complex  when  efficient  rewriting  is  required  or  complex  secu¬ 
rity  policies  are  to  be  enforced,  the  rewriter  becomes  a  significant 
addition  to  the  system’s  tmsted  computing  base. 

In  this  paper,  we  present  Mobile,  an  extension  to  the  .NET  CIL 
that  makes  it  possible  to  automatically  verify  IRM’s  using  a  static 
type-checker.  Mobile  (MOnitorable  BIL  with  Effects)  is  an  exten¬ 
sion  of  BIL  (Baby  Intermediate  Language)  da,  a  substantial  frag¬ 
ment  of  managed  .NET  CIL  that  was  used  to  develop  generics  for 
.NET  (T9).  Mobile  programs  are  CIL  programs  with  additional  typ¬ 
ing  annotations  that  track  an  abstract  representation  of  program 
execution  history.  These  typing  annotations  allow  a  type-checker 
to  verify  statically  that  the  runtime  checks  in-lined  into  the  un¬ 
trusted  program  suffice  to  enforce  a  specified  security  policy.  Once 
type-checked,  the  typing  annotations  can  be  erased,  and  the  self¬ 
monitoring  program  can  be  safely  executed  as  normal  CIL  code. 
This  verification  process  allows  a  rewriter  to  be  removed  from  the 
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Figure  1.  A  Mobile  load  path 


trusted  computing  base  and  replaced  with  a  (simpler)  type-checker. 
Even  when  the  rewriter  is  small  and  therefore  comparable  in  size 
to  the  type-checker,  type-checking  constitutes  a  useful  level  of  re¬ 
dundancy  that  provides  greater  assurance  than  trusting  the  rewriter 
alone.  Mobile  thus  leverages  the  power  of  IRM’s  while  using  the 
type-safety  approach  to  keep  the  trusted  computing  base  small. 

Figure  [T]  summarizes  a  typical  load  path  on  a  system  that  ex¬ 
ecutes  IRM’s  written  in  Mobile.  Untrusted,  managed  CIL  code  is 
first  automatically  rewritten  according  to  a  security  policy,  yield¬ 
ing  an  annotated,  self-monitoring  program  written  in  Mobile.  The 
rewriting  can  be  performed  by  either  a  code  producer  or  by  a 
client  machine  receiving  the  untrusted  code.  Since  the  rewriter, 
and  therefore  the  self-monitoring  program,  remains  untrusted,  the 
self-monitoring  program  is  then  passed  to  a  trusted  type-checker 
that  certifies  the  code  with  respect  to  the  original  security  policy. 
Code  that  satisfies  the  security  policy  will  be  approved  by  the  type- 
checker,  and  is  therefore  safe  to  execute;  code  that  is  not  well-typed 
will  be  rejected  and  would  indicate  a  failure  of  the  rewriter. 

In  this  paper  we  focus  on  robust  certification  of  Mobile  code. 
Techniques  for  efficient  rewriting  are  left  to  future  work,  but  we 
describe  a  naive  rewriter  and  suggest  some  strategies  for  optimiz¬ 
ing  it  in  Our  prototype  implementation  of  Mobile  consists  of  a 
type-checker  that  verifies  sound  rewriting  with  respect  to  security 
policies  expressed  as  tu-regular  expressions.  The  implementation 
can  verify  both  single-threaded  and  multi-threaded  managed  CIL 
applications,  and  it  supports  language  features  beyond  those  mod¬ 
eled  by  BIL,  such  as  exceptions  and  finalizers. 

2.  Related  Work 

Type-systems  A.4  1211  and  Ahist  1281  enforce  history-based  security 
policies  over  languages  based  on  the  A-calculus.  In  both,  program 
histories  are  tracked  at  the  type-level  using  effect  types  that  repre¬ 
sent  an  abstraction  of  those  global  histories  that  might  have  been 
exhibited  by  the  program  prior  to  control  reaching  any  given  pro¬ 
gram  point. 

Mobile  differs  from  Ayi  and  Ahist  by  tracking  history  on  a  per- 
object  basis.  That  is,  both  A^  and  Ahist  represent  a  program’s  history 
as  a  finite  or  infinite  sequence  of  global  program  events,  where  the 
set  of  all  possible  global  program  events  is  always  finite.  Policies 
that  are  only  expressible  using  an  infinite  set  of  global  program 
events  (e.g.,  events  parameterized  by  object  instances)  are  there¬ 


fore  not  enforceable  by  A.4  or  Ahist-  For  example,  the  policy  that 
every  opened  file  must  be  closed  by  the  time  the  program  termi¬ 
nates  is  not  enforceable  by  either  Xa  or  Ahist  when  the  number  of 
file  objects  that  could  be  allocated  during  the  program’s  execution 
is  unbounded.  In  object-oriented  languages  such  as  the  .NET  CIL, 
policies  concerning  unbounded  collections  of  objects  arise  natu¬ 
rally,  so  it  is  not  clear  how  Xa  or  Ahist  can  be  extended  to  such  set¬ 
tings.  Mobile  enforces  policies  that  are  universally  quantified  over 
objects  of  any  given  class,  and  therefore  allows  objects  to  be  treated 
as  first-class  in  policy  specifications. 

PCC  has  been  proposed  as  a  framework  for  supporting  certify¬ 
ing  rewriting  using  temporal  logic  (3).  The  approach  is  potentially 
powerful,  but  does  not  presently  support  languages  that  include  ex¬ 
ceptions,  concurrency,  and  other  features  found  in  real  program¬ 
ming  languages  (2)  p.  173].  It  is  therefore  unclear  whether  proof 
size  and  verification  speed  would  scale  well  in  practical  settings. 

CQual  im  and  Vault  (T)  are  C-like  languages  that  enforce 
history-based  properties  of  objects  by  employing  a  flow-sensitive 
type  system  based  on  alias  types  1291.  Security-relevant  objects  in 
CQual  or  Vault  programs  have  their  base  types  augmented  with 
type  qualifiers,  which  statically  track  the  security-relevant  state  of 
the  object.  A  type-checker  then  determines  if  any  object  might 
enter  a  state  at  runtime  that  violates  the  security  policy.  Vault’s 
type  system  additionally  includes  variant  types  that  allow  a  runtime 
value  to  reflect  an  object’s  current  state.  The  Vault  type-checker 
identifies  instructions  that  test  these  state  values  to  ensure  that  those 
tests  will  prevent  security  violations  when  the  program  is  executed. 

Fugue  (Sj  is  a  static  verifier  based  on  Vault  that  uses  programmer- 
supplied  specifications  to  find  bugs  in  .NET  source  code.  It  verifies 
policies  that  constrain  the  use  of  system  resources  or  that  perscribe 
protocols  that  constrain  the  order  in  which  methods  may  be  called 
on  objects.  Fugue  supports  any  source  language  that  compiles  to 
managed  .NET  CIL  code,  but  it  does  not  support  exceptions,  fi¬ 
nalizers,  or  concurrency.  It  additionally  lacks  a  formal  proof  of 
soundness  for  its  aliasing  analysis  and  type  system. 

Inspired  by  CQual,  Vault,  and  Fugue,  our  work  scales  these 
ideas  up  to  a  large  existing  programming  language — the  full  man¬ 
aged  .NET  CIL  (minus  reflection) — while  providing  a  formal  proof 
of  soundness.  In  scaling  up  to  a  larger-scale  language,  we  adopt 
a  somewhat  different  approach  to  tracking  object  security  states 
at  the  type  level.  CQual,  Vault,  and  Fugue  assign  linear  types  to 
security-relevant  objects  (and,  in  the  case  of  Vault,  to  runtime  state 
values),  and  use  aliasing  analyses  to  track  changes  to  items  with 
linear  types.  However,  it  is  not  clear  how  such  analyses  can  be  ex¬ 
tended  to  support  concurrency  or  to  support  an  important  technique 
commonly  used  by  IRM’s  to  track  object  security  states,  wherein 
security-relevant  objects  are  paired  with  runtime  values  that  record 
their  states,  and  then  such  pairs  are  permitted  to  leak  to  the  heap. 
Existing  alias  analyses  cannot  easily  track  items  that  are  permitted 
to  leak  to  the  heap  arbitrarily,  or  that  are  shared  between  threads. 

We  therefore  take  the  approach  of  L^  (22I,  wherein  linearly- 
typed  items  are  permitted  to  leak  to  the  heap  by  packing  them  into 
shared  data  structures  with  limited  interfaces.  These  shared  object- 
state  pairs,  called  packages,  can  be  aliased  arbitrarily  and  are  not 
tracked  by  the  type  system.  Mobile  provides  trusted  operations  for 
packing  and  unpacking  linear-typed  items  to  and  from  shared  pack¬ 
age  objects.  To  perform  any  (security-relevant)  operation  that  might 
change  a  value  with  linear  type,  it  must  first  be  unpacked  from  any 
package  that  contains  it.  As  with  ownership  types  Eia,  packing 
and  unpacking  operations  are  implemented  as  destructive  reads,  so 
that  only  one  thread  can  perform  security-relevant  operations  on  a 
given  security-relevant  object  at  a  time.  Mobile’s  type  system  and 
the  CLI  permissions  system  are  both  leveraged  to  maintain  invari¬ 
ants  linking  an  object  to  an  accurate  runtime  representation  of  its 
state. 


3.  Overview 

A  Mobile  security  policy  identifies  a  set  of  security-relevant  object 
classes  and  assigns  a  set  of  acceptable  traces  to  each  such  class. 
A  trace  is  a  finite  or  infinite  sequence  of  security-relevant  events — 
program  operations  that  take  a  security-relevant  object  as  an  argu¬ 
ment.  Our  implementation  expresses  security  policies  as  tj-regular 
expressions  over  the  alphabet  of  events,  but  the  formalisms  pre¬ 
sented  in  this  article  can  be  leveraged  to  support  alternative  policy 
languages  as  well.  A  Mobile  program  satisfies  the  security  policy  if 
for  every  complete  run  of  the  program,  (i)  if  the  run  is  finite  (i.e.,  the 
program  terminates),  the  sequence  of  security-relevant  events  per¬ 
formed  on  every  object  allocated  during  that  run  is  a  member  of  the 
set  of  traces  that  the  security  policy  has  assigned  to  that  object’s 
class;  and  (ii)  if  the  run  is  infinite  (i.e.,  the  program  does  not  ter¬ 
minate),  at  each  step  of  the  run  the  sequence  of  security-relevant 
events  performed  so  far  on  each  security-relevant  object  is  a  prefix 
of  a  member  of  the  set  of  traces  assigned  to  that  object’s  class. 

For  example,  p.  5]  proposes  a  security  policy  involving  a 
WebPageFetcher  class  for  which  proper  usage  is  to  call  the  Open 
method  to  acquire  the  resource,  the  GetPage  method  to  use  the  re¬ 
source,  and  the  Close  method  to  release  the  resource.  A  Mobile 
policy  that  requires  programs  to  open  web  pages  before  reading 
them,  allows  at  most  three  reads  per  opened  page,  and  requires 
programs  to  close  web  pages  before  the  program  terminates  (but 
allows  them  to  remain  open  on  runs  that  never  terminate),  might 
assign  (0  (G  U  U  G®)  C)“  as  the  set  of  acceptable  traces  for  class 
WebPageFetcher  (where  0,  G,  and  C  denote  Open,  GetPage,  and 
Close  events,  respectively,  and  ut  denotes  finite  or  infinite  repeti¬ 
tion).  Note  that  this  policy  can  only  be  enforced  by  a  mechanism 
that  tracks  events  at  a  per-object  level. 

Although  Mobile  security  policies  model  events  as  operations 
performed  on  objects,  global  events  that  do  not  concern  any  par¬ 
ticular  object  can  be  encoded  as  operations  on  a  global  object  that 
is  allocated  at  program  start  and  destroyed  at  program  termination. 
Thus,  Mobile  policies  can  regard  global  events,  per-object  events, 
and  combinations  of  the  two. 

For  example,  one  might  modify  the  example  policy  above  by  ad¬ 
ditionally  requiring  that  at  most  ten  network  sends  may  occur  dur¬ 
ing  the  lifetime  of  the  program.  In  that  case,  the  global  object  would 
additionally  be  identified  as  a  security-relevant  object,  a  Send 
method  call  performed  on  any  System .  Net .  Sockets .  Socket  ob¬ 
ject  would  be  identified  as  a  security-relevant  event  for  the  global 
object,  and  the  global  object  would  be  assigned  the  set  of  traces 
denoted  by  e  U  S  U  S^  U  •  •  ■  U  S^®  (where  S  denotes  a  Send  event). 

A  rewriter  that  produces  self-monitoring  programs  from  un¬ 
trusted  CIL  code  is  expected  to  produce  well-typed  Mobile  code, 
so  that  the  policy-adherence  theorem  can  be  used  to  guarantee  that 
it  is  safe  to  execute.  For  this  rewriting  task  to  be  feasible.  Mobile’s 
type  system  must  be  flexible  enough  to  permit  rewriters  to  insert 
runtime  security  checks — well-typed  code  that  tracks  the  state  of 
security-relevant  objects  at  runtime,  testing  aspects  of  the  state  that 
cannot  be  verified  statically.  To  that  end.  Mobile  supports  a  pack 
operation  that  pairs  a  security-relevant  object  with  a  runtime  value 
(e.g.,  an  integer)  representing  an  abstraction  of  the  object’s  cur¬ 
rent  state,  and  that  encapsulates  them  into  a  two-field  package  ob¬ 
ject.  Mobile’s  unpack  operation  can  be  used  to  unpack  a  package, 
yielding  the  original  object  that  was  packed  along  with  the  runtime 
value  that  represents  its  state.  Mobile  programs  can  then  test  this 
runtime  value  to  infer  information  about  the  associated  object’s 
state.  Both  pack  and  unpack  are  implemented  as  CIL  method 
calls  to  a  small  trusted  library  (about  ten  lines  of  C#  code). 

To  keep  type-checking  tractable.  Mobile  does  not  allow  security¬ 
relevant  operations  on  objects  that  are  packed.  A  package  class’s 
two  fields  are  declared  to  be  private  so  that,  to  access  a  security¬ 
relevant  object  directly  and  perform  operations  on  it,  it  must  first 


be  unpacked.  While  unpacked,  Mobile  allows  only  limited  alias¬ 
ing  of  security-relevant  objects — none  of  their  aliases  can  escape 
to  the  heap.  To  enforce  this  restriction,  the  unpack  operation  is 
implemented  as  a  destructive  read,  preventing  the  package  from 
being  unpacked  again  before  it  is  re-packed.  Packages,  however, 
are  permitted  to  escape  to  the  heap  and  to  undergo  unlimited  alias¬ 
ing.  These  restrictions  allow  the  type-checker  to  statically  track 
histories  of  unpacked  objects  and  to  ensure  that  packed  objects  are 
always  paired  with  a  value  that  accurately  reflects  their  state.  When 
an  object  is  packed,  it  is  safe  for  the  type-checker  to  forget  whatever 
information  might  be  statically  known  about  the  object,  keeping  the 
type-checking  algorithm  tractable  and  affording  the  rewriter  a  dy¬ 
namic  fallback  mechanism  when  static  analysis  cannot  verify  all 
security-relevant  operations. 

When  pack  and  unpack  are  implemented  as  atomic  opera¬ 
tions,  Mobile  can  also  enforce  security  policies  in  concurrent  set¬ 
tings.  In  such  a  setting.  Mobile’s  type  system  maintains  the  invari¬ 
ant  that  each  security-relevant  object  is  either  packed  or  held  by 
at  most  one  thread.  Packed  objects  are  always  policy-adherent  (or 
their  finalizers  must  bring  them  to  a  policy-adherent  state  at  pro¬ 
gram  termination;  see  !|^,  whereas  unpacked  objects  are  tracked 
by  the  type  system  to  ensure  that  they  return  to  a  policy-adherent 
state  before  they  are  relinquished  by  the  thread. 

Implementing  pack  and  unpack  as  atomic  swaps  is  a  some¬ 
what  blunt  approach,  but  it  is  still  powerful  enough  to  support  use¬ 
ful  and  effective  rewriting  strategies.  Using  the  above  operations,  a 
naive  rewriter  can  implement  state-based  histories  by  simply  repre¬ 
senting  security-relevant  objects  as  packages.  Whenever  a  security¬ 
relevant  operation  is  to  be  performed,  the  rewriter  would  insert  code 
to  first  unpack  the  package  and  test  the  object’s  runtime  state,  then 
perform  the  security-relevant  operation  only  if  the  test  succeeds 
(possibly  terminating  otherwise),  and  finally  repackage  the  object 
with  updated  state. 

This  strategy  suffices  to  implement  any  state-based  history  but 
might  result  in  inefficient  code  if  security-relevant  operations  are 
frequent.  Thus,  Mobile’s  type  system  also  makes  it  possible  to 
avoid  some  of  these  dynamic  operations  when  policy-adherence 
can  be  proved  statically.  For  example,  a  more  sophisticated  rewriter 
could  in  some  cases  insert  code  to  perform  numerous  security¬ 
relevant  operations  consecutively  without  any  dynamic  checks.  In¬ 
stead  of  dynamic  checks,  the  rewriter  could  add  typing  annotations 
that  prove  to  the  type-checker  that  the  omitted  checks  are  unneces¬ 
sary  for  preventing  a  security  violation.  Substituting  annotations  for 
dynamic  checks  in  this  way  is  often  possible  in  straight-line  code 
or  tight  loops  that  do  not  leak  security-relevant  objects  to  the  heap. 
However,  when  objects  do  escape  to  the  heap,  the  type  system  is 
not  sufficiently  powerful  to  track  them  and  dynamic  checks  would 
usually  be  necessary  in  order  to  prove  that  a  security  violation  can¬ 
not  occur.  Thus,  Mobile’s  type  system  is  sufficiently  expressive  that 
rewriters  can  avoid  some  but  not  all  dynamic  checks. 

Our  implementation  of  Mobile  models  security  policies  as 
finite-state  security  automata.  This  approach  is  appealing  because 
it  is  simple,  practical,  it  introduces  minimal  extra  state  to  untrusted 
programs,  and  it  seems  to  cover  most  of  the  enforceable  secu¬ 
rity  policies  discussed  in  the  literature.  However,  the  formalisms 
presented  in  this  paper  do  not  assume  any  particular  method  of 
representing  object  states  at  runtime.  Rather,  we  parameterize  the 
framework  in  terms  of  arbitrary  state  representations  and  state  tests 
so  that  alternative  implementations  can  be  realized  in  the  future. 
For  example,  future  implementations  might  track  object  states  us¬ 
ing  LTL  expressions  or  even  by  recording  an  object’s  complete 
history  at  runtime.  Thus,  Mobile  constitutes  a  framework  general 
enough  to  reason  about  many  different  in-lining  strategies  used  by 
IRM’s. 
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4.1  The  Abstract  Machine 

Figure|^gives  the  Mobile  instruction  set.  Like  BIL,  Mobile’s  syn¬ 
tax  is  written  in  postfix  notation.  In  addition  to  BIL  instructions^ 
Mobile  includes 


•  instruction  evt  e,  which  performs  security-relevant  operation  e 
on  an  object  (where  e  is  some  unique  identifier,  such  as  “open”, 
that  we  associate  with  each  security-relevant  operation), 

•  instructions  newpackage  and  newhist  for  creating  pack¬ 
ages  and  runtime  state  values, 

•  instructions  pack  and  unpack  for  packing/unpacking  objects 
and  runtime  state  values  to/from  packages, 

•  instruction  condst,  which  dynamically  tests  a  runtime  state 
value,  and 


the  pseudo-instructions  ^  and  ret,  which  do  not  appear  in 
source  code  but  are  introduced  in  the  intermediate  stages  of  the 
small-step  semantics  presented  in  i  4.2  (Instruction  is  a  term 
that  has  been  reduced  to  value  v,  ana  instruction  ret  pops  the 
current  stack  frame  at  the  end  of  a  method  call.) 


These  abstract  instructions  model  real  CIL  instructions.  For  ex¬ 
ample,  if  calls  to  method  m  are  security-relevant  operations,  the 
CIL  instruction  that  invokes  m  on  object  o  is  modeled  by  the 
Mobile  instruction  sequence:  o  evt  Cm',  o  callvirt  Cwm.Sig^.  A 
description  of  how  our  implementation  models  other  CIL  instruc¬ 
tions  is  given  in  ^ 

Figure  provides  Mobile’s  type  system.  Mobile  types  consist 
of  void  types,  integers,  classes,  and  history  abstractions  (the  types 
of  runtime  state  values).  The  type  of  each  unpacked,  security¬ 
relevant  object  C{i)  is  parameterized  by  an  object  identity  variable 
I  that  uniquely  identifies  the  object.  All  aliases  of  the  object  have 
types  with  the  same  object  identity  variable,  but  other  unpacked 
objects  of  the  same  class  have  types  with  different  object  identity 

'  For  simplicity,  we  omit  BIL’s  value  classes  and  managed  pointers  from 
Mobile,  but  otherwise  include  all  BIL  types  and  instructions. 


Figure  4.  Mobile  subtyping 


variables.  The  types  C(?)  of  packed  classes  and  security-irrelevant 
classes  do  not  include  object  identity  variables,  and  their  instances 
are  therefore  not  distinguishable  by  the  type  system.  We  consider 
Mobile  terms  to  be  equivalent  up  to  alpha  conversion  of  bound 
variables. 

The  types  of  runtime  state  values  are  parameterized 

both  by  the  class  type  C  of  the  object  to  which  they  refer  and  by  a 
history  abstraction  H — an  w-regular  expression  (plus  variables  and 
intersection)  that  denotes  a  set  of  traces.  In  such  an  expression,  u) 
denotes  finite  or  infinite  repetition. 

Closed  (i.e.,  variable-less)  history  abstractions  conform  to  a 
subset  relation;  we  write  Hi  C  H2  if  the  set  of  traces  denoted 
by  Hi  is  a  subset  of  the  set  of  traces  denoted  by  H2-  This  subset 
relation  induces  a  natural  subtyping  relation  X  given  in  Figure 
Observe  that  the  subtyping  relation  in  Figure]^ does  not  recognize 
class  subtyping  of  security-relevant  classes.  We  leave  support  for 
subtyping  of  security-relevant  classes  to  future  work. 

Type  variables  in  Mobile  types  are  bound  by  typing  contexts 
r,  which  assign  class  or  package  types  to  object  identity  variables 
i  and  declare  any  history  abstraction  variables  Q.  Object  identity 
variables  can  additionally  appear  in  object  history  maps  which 
associate  a  history  abstraction  H  with  each  object  identity  variable 
that  corresponds  to  an  unpacked,  security-relevant  object.  Since 
object  identity  variables  uniquely  identify  each  object  instance, 
object  history  maps  can  be  seen  as  a  spatial  conjunction  (*)  (25) 
of  assertions  about  the  histories  of  the  various  unpacked  objects  in 
the  heap. 

A  complete  Mobile  program  consists  of: 
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Class  methods 
Class  policies 


C 

field  ■.  (C  X  f)  ^  yt 
methodbody  :  (Cc.m.Sig)  — >  I 
policy  :  C  ^  H 


result 


0 

H 

l 

repc(H) 
o  ::= 

objcift 
pkg{e,  rcp^{H)) 
pkg{-) 

h  ::=  ii  I— >  Oi 

a  ::=  (vq,  .  ■  ■  ,v„) 
s  ::=  {cLQ, .  .  .  ,  dn} 
t/i  ::=  (h,s) 


void 
integer 
heap  pointer 
runtime  state  value 
heap  elements 
object 

filled  package 
empty  package 

heap 

ai'guments 

stack 

small-step  store 


Figure  5.  The  Mobile  memory  model 


We  also  use  the  notation  fields{C)  to  refer  to  the  number  of  fields 
in  class  C.  Method  signatures  Sig  will  be  described  in  §4.3| 


4.2  Operational  Semantics 

Unlike  im,  we  provide  a  small-step  operational  semantics  for 
Mobile  rather  than  a  large-step  semantics,  so  as  to  apply  the  policy 
adherence  theorems  presented  in  §4.4|  to  programs  that  do  not 
terminate  or  that  enter  a  bad  state. 

In  Mobile’s  small-step  memory  model,  presented  in  Figure]^ 
objects  consist  not  only  of  an  assignment  of  values  to  fields  but  also 
a  trace  e  that  records  a  history  of  the  security-relevant  operations 
performed  on  the  object.  Although  our  model  attaches  a  history 
trace  to  each  object,  we  prove  in  §4.4|that  it  is  unnecessary  for  the 
virtual  machine  to  track  and  store  object  traces  because  well-typed 
Mobile  code  never  exhibits  a  trace  that  violates  the  security  policy. 

The  small-step  operational  semantics  of  Mobile,  given  in  Fig¬ 
ures  |^and|^  define  how  a  given  store  t/)  and  instruction  /  steps  to  a 
new  store  ip  and  instruction  I' ,  written  ip,  I  ip' ,  I' .  Rulesf^  ■  18 
model  the  behavior  of  the  new  instructions  introduced  by  Mobile. 
Rule  1 13|  appends  event  ei  to  the  sequence  of  events  exhibited  on 
object  f .  Rule|14|introduces  a  new  package  object  to  the  local  con¬ 
text.  Rule flSl assigns  an  object  £'  and  runtime  state  value  rep^(H) 
to  the  fields  of  package  £.  Rule  |16|  yields  the  object  and  runtime 
state  value  stored  in  package  £  and  erases  £’s  fields. 

Rules  [T7|and|18|use  notation  not  previously  defined  and  there¬ 
fore  deserve  special  note.  Runtime  operations  teste, fe  and  hcc,fc 
test  runtime  state  values  and  construct  new  runtime  state  values, 
respectively.  Rather  than  fixing  these  two  operations,  we  allow 
Mobile  to  be  extended  with  unspecified  implementations  of  them. 
Different  implementations  of  teste,*  and  hcc,*  can  therefore  be 
used  to  allow  Mobile  to  support  different  collections  of  security 
policies.  For  example,  a  Mobile  system  that  supports  security  poli¬ 
cies  expressed  as  DFA’s  might  implement  runtime  state  values  as 
32-bit  integers  and  might  support  tests  that  compare  runtime  state 
values  to  integer  constants  (to  determine  which  state  the  DFA  is 
in).  In  that  case,  one  could  define  for  each  k  £  0..2^^,  hcc,fc  i)  =  k 
and  teste,*  (*)  =  {1  if  *  =  A:,  else  0}.  A  more  powerful  (but  more 
computationally  expensive)  Mobile  system  might  implement  run¬ 
time  state  values  as  dynamic  data  structures  that  record  an  object’s 
entire  trace  and  might  provide  tests  to  examine  such  structures.  In 
this  paper,  we  assume  only  that  a  countable  collection  of  state  value 
constructors  and  tests  exists  and  that  this  collection  adheres  to  typ¬ 
ing  constraints [T^  1^1^  and|^presented  in  §4.3| 
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Figure  7.  Small-step  Operational  Sematics  for  Mobile 


1  (newobj  C())  starg  1; 

2  (Idarg  1)  evt  ei; 

3  (Idarg  1)  evt  62; 

4  (newpackage  C)  starg  2; 

5  (Idarg  2)  (Idarg  1)  (newhist  C,  0)  pack; 

6  (...)  (Idarg  2)  stfid  .  . . ; 

7  ((Idarg  2)  unpack  4)  starg  3; 

8  (Idarg  3)  ((Idarg  4)  evt  ei)  (...)  condst  C,0 

Figure  8.  Sample  Mobile  program 


The  operational  semantics  given  in  Figure^ are  for  a  single- 
threaded  virtual  machine  without  support  for  finalizers.  To  model 
concurrency,  one  could  extend  our  stacks  to  consist  of  multi¬ 
ple  threads  and  add  a  small-step  rule  that  non-deterministically 
chooses  which  thread  to  execute  next.  Finalizers  could  be  modeled 
by  adding  another  small-step  rule  that  non-deterministically  forks 
a  finalizer  thread  whenever  an  object  is  unreachable.  Our  imple¬ 
mentation  supports  concurrency  and  finalizers,  but  to  simplify  the 
presentation,  we  leave  the  analysis  of  these  language  features  to 
future  work. 

4.3  Type  System 

Mobile’s  type  system  considers  each  Mobile  term  to  be  a  linear  op¬ 
erator  from  a  history  map  and  frame  list  (describing  the  initial  heap 
and  stack,  respectively)  to  a  new  history  map  and  frame  list  (de¬ 
scribing  the  heap  and  stack  yielded  by  the  operation)  along  with  a 
return  type.  That  is,  we  write  r  h  I  :  )  -<3  3r'.(^>';  Fr  r') 

if  term  I,  when  evaluated  in  typing  context  F,  takes  history  map  T' 
and  frame  list  Fr  (in  which  any  typing  variables  are  bound  in  con¬ 
text  T)  to  new  history  map  T*'  and  new  frame  list  Fr  ,  and  yields 
a  value  of  type  t'  (if  it  terminates).  Any  new  typing  variables  ap¬ 
pearing  in  Fr  and  t'  are  bound  in  context  T'.  A  method  signature 
(see  Figure]^  is  the  type  assigned  to  the  term  comprising  its  body. 

Below,  we  provide  an  informal  description  of  Mobile’s  typing 
rules  by  walking  the  type-checking  algorithm  through  the  sample 
Mobile  program  given  in  Figure]^  A  complete  list  of  typing  rules 
is  stated  formally  in  the  appendix. 

Line  1  of  the  sample  program  creates  a  new  object  of  class 
C  and  stores  it  in  local  register  1.  When  a  new  security-relevant 
object  is  created,  Mobile’s  type  system  assigns  it  a  fresh  object 
identity  variable  1.  The  return  type  of  the  newly  created  object  is 
thus  C{F)  and  the  new  history  map  yielded  by  the  operation  satisfies 
—  e;  that  is,  new  objects  are  initially  assigned  the  empty 

trace. 

As  security-relevant  events  are  performed  on  the  object,  the 
type  system  tracks  these  changes  by  statically  updating  its  history 
map  to  append  these  new  events  to  the  sequence  it  recorded  in 
its  history  map.  So  for  example,  after  processing  lines  2-3  of  the 
sample  program,  which  perform  events  ei  and  62  on  the  object  in 
local  register  1,  the  type-checker’s  new  history  map  would  satisfy 
=  6162.  At  each  point  that  a  security-relevant  event  is 
performed,  the  type  system  ensures  that  the  new  trace  satisfies 
a  prefix  of  the  security  policy.  For  example,  when  type-checking 
line  3,  the  type-checker  would  verify  that  6162  C  pre{policy{C)), 
where  policy  {C)  denotes  the  set  of  acceptable  traces  assigned  by 
the  security  policy  to  class  C,  and  pre{policy{C))  denotes  the  set 
of  prefixes  of  members  of  set  policy  (C). 

Security-relevant  objects  of  type  C{£)  are  like  typical  objects 
except  that  they  are  not  permitted  to  escape  to  the  heap.  That  is, 
they  cannot  be  assigned  to  object  fields.  In  order  to  leak  a  security¬ 
relevant  object  to  the  heap,  a  Mobile  program  must  first  store  it  in 
a  package  using  a  pack  instruction.  This  requires  three  steps:  (1) 
A  package  must  be  created  via  a  newpackage  instruction.  (2)  A 
runtime  state  value  must  be  created  that  accurately  reflects  the  state 


of  the  object  to  be  packed.  This  is  accomplished  via  the  newhist 
instruction,  which  is  described  in  more  detail  below.  (3)  Finally, 
the  pack  operation  is  used  to  store  the  object  and  the  runtime 
state  value  into  the  package.  Lines  4  and  5  of  the  sample  program 
illustrate  these  three  steps.  Line  4  creates  a  new  package  and  stores 
it  in  local  register  2.  Line  5  then  fills  the  package  using  the  object 
in  local  register  1  along  with  a  newly  created  runtime  state  value. 

In  order  for  Mobile’s  type  system  to  accept  a  pack  operation, 
it  must  be  able  to  statically  verify  that  the  runtime  state  value 
is  an  accurate  abstraction  of  the  object  being  packed.  That  is,  if 
the  runtime  state  value  has  type  then  the  type  system 

requires  that  C  H  where  i  is  the  object  identity  variable 

of  the  object  being  packed.  Additionally,  since  packed  objects  are 
untracked  and  therefore  might  continue  to  exist  until  the  program 
terminates,  packed  objects  must  satisfy  the  security  policy.  That  is, 
we  require  that  C  policyiC). 

Packages  that  contain  security-relevant  objects  can  leak  to  the 
heap,  as  illustrated  by  line  6  of  the  sample  program,  which  stores 
the  package  to  a  field  of  some  other  object.  Since  only  packed 
objects  can  leak  to  the  heap,  the  restriction  that  packed  objects  must 
be  in  a  policy-adherent  state  is  a  potential  limitation  of  the  type 
system.  That  is,  it  might  often  be  desirable  to  leak  an  object  that  is 
not  yet  in  a  policy-adherent  state  to  the  heap,  but  later  retrieve  it  and 
restore  it  to  a  policy-adherent  state  before  the  program  terminates. 
In  !|^we  show  how  Mobile  implementations  can  use  finalizer  code 
to  avoid  this  restriction  and  leak  objects  to  the  heap  even  when  they 
are  not  yet  in  a  policy-adherent  state. 

After  a  pack  operation,  the  type  system  removes  object  identity 
variable  I  from  the  history  map.  Hence,  after  line  5  of  the  sample 
program,  is  undefined  and  the  object  that  was  packed  be¬ 

comes  inaccessible.  If  the  program  were  to  subsequently  attempt 
to  load  from  local  register  1  (before  replacing  its  contents  with 
something  else),  the  type-checker  would  reject  the  code  because 
that  register  now  contains  a  value  with  an  invalid  type.  Object  iden¬ 
tity  variable  I  can  therefore  be  thought  of  as  a  capability  that  has 
been  revoked  from  the  local  scope  and  given  to  the  package. 

In  order  to  perform  more  security-relevant  events  on  an  object, 
a  Mobile  program  must  first  reacquire  a  capability  for  the  object  by 
unpacking  the  object  from  its  package  via  an  unpack  instruction. 
Line  7  of  the  sample  program  unpacks  the  package  in  local  regis¬ 
ter  2,  storing  the  extracted  object  in  local  register  3  and  storing  the 
runtime  state  value  that  was  packaged  with  it  in  local  register  4. 
Since  packages  and  the  objects  they  contain  are  not  tracked  by  the 
type  system,  the  type  system  cannot  statically  determine  the  history 
of  a  freshly  unpacked  object.  All  that  is  statically  known  is  that  the 
runtime  state  value  that  will  be  yielded  at  runtime  by  the  unpack 
instruction  will  be  an  accurate  representation  of  the  unpacked  ob¬ 
ject’s  history.  To  reflect  this  information  statically,  the  type  system 
assigns  a  fresh  object  identity  variable  (!  to  the  unpacked  object 
and  a  fresh  history  variable  Q  to  the  unknown  history.  The  unpacked 
object  and  runtime  state  value  then  have  types  CIF)  and 
respectively,  and  the  new  history  map  satisfies  '^'  ((!)  =  6.  The 
type  C(?)  of  a  package  can  hence  be  thought  of  as  an  existential 
type  binding  type  variables  £!  and  Q. 

If  the  sample  program  were  at  this  point  to  perform  security¬ 
relevant  event  e  on  the  newly  unpacked  object.  Mobile’s  type  sys¬ 
tem  would  reject  because  it  would  be  unable  to  statically  verify 
that  Qe  C  policy  (C)  (since  nothing  is  statically  known  about  his¬ 
tory  9).  However,  a  Mobile  program  can  perform  additional  evt 
operations  on  the  object  by  first  dynamically  testing  the  runtime 
state  value  yielded  by  the  unpack  operation.  If  a  Mobile  program 
dynamically  tests  a  value  of  type  Mobile’s  type  system 

can  statically  infer  information  about  history  6  within  the  branches 
of  the  conditional.  For  example,  if  a  condst  instruction  is  used 
to  test  a  value  with  type  y{ep^{6)  for  equality  with  a  value  of  type 


'I{ep^{e\e2),  then  in  the  positive  branch  of  the  conditional,  the  type 
system  can  statically  infer  that  6  =  6162.  If  policyiC)  =  (6162)“, 
then  a  Mobile  program  could  execute  I  evt  ei  within  the  positive 
branch  of  such  a  conditional  (where  I  is  the  object  that  was  un¬ 
packed),  because  616261  C  pre((6i62)“);  but  the  type-checker 
would  reject  a  program  that  executed  I  evt  62  in  the  positive 
branch,  since  616262  2  pre((6i62)“). 

Mobile  supports  many  possible  schemes  for  representing  histo¬ 
ries  at  runtime  and  for  testing  them,  so  rather  than  fixing  particular 
operations  for  constructing  runtime  state  values  and  particular  op¬ 
erations  for  testing  them,  we  instead  assume  only  that  there  exists  a 
countable  collection  of  constructors  newhist  C,  k  and  condition¬ 
als  condst  C,  k  for  all  integers  k,  that  construct  runtime  state  val¬ 
ues  and  test  runtime  state  values  (respectively)  for  objects  of  class 
C.  We  then  abstractly  define  HCc,k{-  ■  •)  to  be  the  type  y{ep^{H) 
of  a  history  value  constructed  using  constructor  k  for  security¬ 
relevant  class  C,  and  we  define  ctx'^  ki^’  ctx'^  ki^^ 

to  be  the  object  history  maps  that  refine  tit  in  the  positive  and  nega¬ 
tive  branches  (respectively)  of  a  conditional  that  performs  test  k  on 
a  history  value  of  type  il{cp^{H).  Mobile  supports  any  such  refine¬ 
ment  that  is  sound  in  the  sense  that 

testc.fc(il')  =  0  ^  2  ctXc^kiH,  (19) 

and 

teste, k{H)  2  0  Vf  2  ctx+j^iH,  (20) 

We  further  assume  that  each  history  type  constructor  HCc,k(-  ■  ■) 
accurately  reflects  its  runtime  implementation,  in  the  sense  that 
for  all  history  value  types  , . . . ,  ^K^Pq  {Hn)  such  that 

n  =  arity{HCc,k),  there  exists  some  H  such  that 

HCc,k{'K}Pe^{H{),. . . ,  liep^J^Hn))  =  1{ep^{H)  (21) 

and 

ticc,k{np(.^  [H\), .  .  .  ,  rep^^  {H„))  =  rep^{H)  (22) 

In  the  sample  program,  suppose  that  history  value  construc¬ 
tor  newhist  C,  0  takes  no  arguments  and  yields  a  runtime  value 
that  represents  history  6162;  and  suppose  that  conditional  test 
condst  C,  0  compares  a  runtime  state  value  to  the  value  that  repre¬ 
sents  history  6162.  Formally,  suppose  that  HCc,o{)  =  tl{e.p^{eie2) 
and  ctej  q(0,  tk)  =  tI/[0  1— >  6162].  Thus,  in  the  positive  branch 
of  such  a  test,  the  type-checker’s  object  history  map  can  be  refined 
by  substituting  6162  for  any  instances  of  the  history  variable  be¬ 
ing  tested.  Then  if  policy(C)  =  (6162)“,  a  Mobile  type-checker 
would  accept  the  sample  program.  In  the  positive  branch  of  the 
conditional  in  line  8,  the  type-checker  would  infer  that  the  object  in 
local  register  4  has  history  6162,  and  therefore  it  is  safe  to  perform 
event  61  on  it.  However,  if  policy{C)  =  616262,  then  the  type- 
checker  would  reject,  because  616261  is  not  a  prefix  of  616262. 

In  the  negative  branch  of  this  conditional  the  type-checker  can 
infer  that  the  object  in  local  register  4  has  a  history  represented  by  a 
state  value  other  than  the  one  that  it  was  tested  against.  The  history 
map  could  therefore  be  refined  by  substituting  history  variable  9 
with  the  union  of  all  of  the  history  abstractions  associated  with  all 
of  the  other  possible  runtime  state  values  defined  for  that  object’s 
class. 

Our  implementation  of  Mobile  implements  history  abstraction 
values  as  integers.  Thus,  it  provides  2®^  newhist  operations  for 
each  security-relevant  class  C,  defining  hcc.^O  =  ^  for  all  k  G 
0..2®^  —  1.  Tests  condst  of  runtime  state  values  are  implemented 
as  equality  comparisons  between  the  integer  runtime  state  value  to 


be  tested  and  an  integer  constant.  Thus,  we  define 

e^enHk] 

ctxc,k{e,  ^)  =  0  n 

for  each  integer  k  G  0..2^^  —  1,  where  Hk  is  a  closed  history  ab¬ 
straction  statically  assigned  to  integer  constant  k.  The  assignments 
of  closed  history  abstractions  Hk  to  integers  k  are  not  trusted,  so 
this  mapping  can  be  defined  by  the  Mobile  program  itself  (e.g.,  in 
settings  where  self-monitoring  programs  are  produced  by  a  com¬ 
mon  rewriter  or  where  separately  produced  programs  do  not  ex¬ 
change  objects)  or  by  the  policy-writer  (in  settings  where  the  map¬ 
ping  must  be  defined  at  a  system  global  level  for  consistency). 

The  above  scheme  allows  a  Mobile  program  to  represent  object 
security  states  at  runtime  with  a  security  automaton  of  2®^  states  or 
less.  Each  state  of  the  automaton  is  assigned  an  integer  constant  k, 
and  history  abstraction  Hk  would  denote  the  set  of  traces  that  cause 
the  automaton  to  arrive  in  state  k. 

4.4  Policy  Adherence  of  Mobile  Programs 

The  operational  semantics  of  Mobile  presented  in  §4.2|  permit 
untyped  Mobile  programs  to  enter  bad  terminal  states — states  in 
which  the  Mobile  program  has  not  been  reduced  to  a  value  but 
no  progress  can  be  made.  For  example,  an  untyped  Mobile  pro¬ 
gram  might  attempt  to  load  from  a  non-existent  field  or  attempt  to 
unpack  an  empty  package  (in  which  case  no  small- step  rule  can 
be  applied).  Mobile’s  type  system  presented  in  §4. 3|  prevents  both 
policy  violations  and  bad  terminal  states,  except  that  it  does  not 
prevent  unpack  operations  from  being  performed  on  empty  pack¬ 
ages.  This  reflects  the  reality  that  in  practical  settings  there  will 
always  be  bad  terminal  states  that  are  not  statically  preventable. 
We  prove  below  that  Mobile  programs  well-typed  with  respect  to 
a  security  policy  will  not  violate  the  security  policy  when  executed 
even  if  they  enter  a  bad  state. 

Formally,  we  define  well-typed  by 

Definition  1.  A  method  C::m.Sig  with  Sig  =  Vri„.('I'i„,  TVi„)  — o 
out ■{'i out,  Front,  t)  is  well-typed  if  and  only  if  there  exists  a 
derivation  for  the  typing  judgment  Fin  h  I  :  {'^in,Frin) 
out out.  Front,  t)  where  /  =  methodbody{C-.:m.Sig). 

Definition  2.  A  Mobile  program  is  well-typed  if  and  only  if  (1) 
for  all  Cr.m.Sig  G  Dom{methodbody),  method  Cr.m.Sig  is 
well-typed,  and  (2)  there  exists  a  method  C-matn'-'.main.Sig^^i^  G 
Dom{methodbody)  with  (n, . . . ,  r„))  ^ 

JT out out.  Front,  Tout)  such  that  for  all  substitutions  a  :  6  ^ 
e  and  all  object  identity  variables G  (Fin,  Tout),  if 'I'out(/)  = 
H  then  (j{H)  C  policyiC). 

Part  2  of  definition  1^  captures  the  requirement  that  a  Mobile  pro¬ 
gram’s  entry  method  must  have  a  signature  that  complies  with  the 
security  policy  on  exit. 

Policy  violations  are  defined  differently  depending  on  whether 
the  program  terminates  normally.  If  the  program  terminates  nor¬ 
mally,  Mobile’s  type  system  guarantees  that  the  resulting  heap  will 
be  policy-adherent;  whereas  if  the  program  does  not  terminate  or 
enters  a  bad  state.  Mobile  guarantees  only  that  the  heap  at  each 
evaluation  step  will  be  prefix-adherent,  where  policy-  and  prefix- 
adherence  are  defined  as  follows: 

Definition  3  (Policy  Adherent).  A  heap  h  is  policy-adherent  if, 
for  all  class  objects  o6y ®  G  Rng{h),  e  C  policy (C). 

Definition  4  (Prefix  Adherent).  A  heap  h  is  prefix-adherent  if,  for 
all  class  objects  obj  G  Rng{h),  e  C  pre {policy (C)). 


To  formalize  the  theorem,  we  first  define  a  notion  of  consistency 
between  a  static  typing  context  and  a  runtime  memory  state.  We  say 
that  a  memory  store  tp  respects  an  object  identity  context  T'  and  a 
list  of  frames  Fr ,  written  F  h  ^  Fr )  if  all  object  fields  and 
stack  slots  in  tp  have  values  of  appropriate  types,  and  the  heap  in  ip 
is  prefix-adherent.  (See  m  for  a  formal  definition.)  The  following 
two  theorems  then  establish  that  well-typed  Mobile  programs  do 
not  violate  the  security  policy. 

Theorem  1  (Terminating  Policy  Adherence).  Assume  that  a 
Mobile  program  is  well-typed,  and  that,  as  per  Definition  1^  its 
main  method  has  signature  Sig  =  VF „ .  (vF 

in  1 

out,  Front,  Tout)-  If  Fin  F  ip  ■  tn,  Fv)  holds  and  if 
Ip,  methodbody{Cmain--main.Sig)  ,  s'),  holds,  then  h'  is 

policy-adherent. 

Proof.  Omitted  for  brevity.  See  CD.  □ 

Theorem  2  (Non-terminating  Prefix  Adherence).  Assume  that 
a  Mobile  program  is  well-typed,  and  assume  that  F  h  7  : 
(■^■Ff)  ^  3F'.(T'';Fr';r)  and  T  h  {h- s)  :  (vF;Fr)  hold.  If 
h  is  prefix-adherent  and  (h,  s),  I  s'),  7'  holds,  then  h'  is 

prefix-adherent. 

Proof.  Omitted  for  brevity.  See  (H.  □ 

An  important  consequence  of  both  of  these  theorems  is  that 
Mobile  can  be  implemented  on  existing  .NET  systems  without 
modifying  the  memory  model  to  store  object  traces  at  runtime. 
Since  a  static  type-checker  can  verify  that  Mobile  code  is  well- 
typed,  and  since  well-typed  code  never  exhibits  a  trace  that  violates 
the  security  policy,  the  runtime  system  need  not  store  or  monitor 
object  traces  to  prevent  security  violations. 

5.  Implementation 

Our  prototype  implementation  of  Mobile  consists  of  a  type-checker 
for  Mobile’s  type  system  extended  to  the  full  managed  subset  of 
Microsoft’s  .NET  CIL  (minus  reflection).  The  type-checker  was 
written  in  Ocaml  (about  one  thousand  lines  of  code)  and  uses 
Microsoft’s  .NET  ILX  SDK  (Ml  to  read  and  manipulate  .NET 
bytecode  binaries.  Mobile  programs  are  .NET  CIL  programs  with 
typing  annotations  encoded  as  .NET  method  attributes.  The  Mobile 
type-checker  reads  these  (untrusted)  annotations  and  verifies  them 
in  the  course  of  type-checking. 

Our  implementation  allows  security  policies  to  identify  method 
calls  as  security-relevant  events.  Thus,  security  policies  can  con¬ 
strain  the  usage  of  resources  provided  by  the  CLR  by  monitoring 
CLR  method  calls  and  the  objects  they  return.  Our  type-checker 
can,  in  principle,  regard  any  CIL  instruction  as  a  security-relevant 
event,  but  we  leave  practical  investigation  of  this  feature  to  future 
work. 

Operations  pack  and  unpack  are  implemented  as  method 
calls  to  the  (very  small)  trusted  C#  library  given  in  Eigure|^  Ob¬ 
serve  that  C#’s  lock  construct  is  used  to  make  both  operations 
atomic.  History  abstraction  values  are  implemented  as  integers. 
Thus,  our  newhist  operation  is  simply  a  ldc.i4  instruction  that 
loads  an  integer  constant  onto  the  evaluation  stack.  Policies  can 
statically  declare  for  each  integer  constant  a  closed  history  abstrac¬ 
tion  that  integer  represents  when  used  as  a  runtime  state  value.  Tests 
of  runtime  state  values  consist  of  equality  comparisons  with  inte¬ 
ger  constants  in  the  manner  described  in  §4.3[  As  described  in  §4.3| 
this  implementation  suffices  to  support  IRM’s  that  model  security 
policies  as  finite-state  security  automata. 

The  type-checker  must  verify  subset  relations  over  the  language 
of  history  abstractions  given  in  Figure]^  Although  deciding  subset 
for  oj-regular  expressions  with  variables  and  intersection  is  not 


class  Package  { 

private  object  obj ; 
private  int  state; 

public  void  Pack(object  o,  int  s)  { 
lock  (this)  {  obj=o;  state=s;  } 

} 

public  object  Unpack(ref  int  s)  { 
lock  (this)  { 
object  o=obj ; 

if  (o==null)  throw  new  EmptyPackage () ; 
obj=null;  s=state; 
return  o ; 

} 

} 

} 


Figure  9.  Implementation  of  pack  and  unpack 


tractable  in  general,  the  task  is  simplified  by  observing  that  real 
Mobile  code  only  introduces  history  variables  at  the  beginnings 
of  expressions  (when  an  object  is  unpacked)  and  only  introduces 
intersections  that  involve  a  variable  and  a  closed  history  abstraction 
(when  a  runtime  state  value  is  tested).  The  resulting  sub-language 
can  be  decided  using  a  simple  regular  expression  subset  algorithm 
(proof  omitted  for  brevity). 

Our  type-checker  also  recognizes  method  annotations  attached 
to  finalizers  of  security-relevant  classes.  A  finalizer’s  precondition 
must  be  satisfied  whenever  an  object  of  its  class  escapes  to  the 
heap  (i.e.,  when  it  is  packed),  since  at  any  point  after  that,  its 
package  object  could  become  orphaned  and  then  garbage-collected. 
By  the  time  a  program  terminates,  all  of  its  objects  are  guaranteed 
to  satisfy  their  finalizers’  postconditions,  since  at  that  point  any 
remaining  objects  will  be  garbage-collected.  This  allows  an  IRM 
to  leak  security-relevant  objects  to  the  heap  (in  packages)  even 
when  they  are  not  yet  in  a  policy-adherent  state,  as  long  as  the 
object’s  finalizer  suffices  to  restore  it  to  a  policy-adherent  state  once 
garbage-collection  occurs. 

To  test  our  implementation,  we  wrote  a  simple  rewriter  like  that 
described  in  and  used  it  to  enforce  a  security  policy  that  al¬ 
lows  each  .NET  network  socket  object  to  accept  at  most  n  con¬ 
nections  during  the  program’s  lifetime  (where  n  is  a  parameter 
specified  by  the  policy-writer).  Such  a  policy  might  be  used,  for 
example,  to  force  applications  to  relinquish  control  of  network 
ports  after  a  certain  amount  of  activity.  We  applied  this  policy  to 
a  small  multithreaded  Webserver  written  in  C#.  The  original  appli¬ 
cation  binary  was  20K  in  size  and  rewriting  did  not  alter  its  size. 
(Padding  introduced  by  the  CLI  binary  format  masked  the  small 
overhead  introduced  by  additional  instructions  and  annotations.) 
Hand-counting  the  material  inserted  by  the  rewriter  revealed  ap¬ 
proximately  83  bytes  in  additional  instructions  and  117  bytes  in 
annotations.  Rewriting  took  0.12  seconds  and  type-checking  took 
0.09  seconds  on  a  1 .8GHz  Pentium.  We  benchmarked  both  the  orig¬ 
inal  and  rewritten  webservers  by  using  WebStone  to  simulate  two 
clients  retrieving  five  webpages  ranging  in  size  from  500  bytes  to 
5  megabytes.  WebStone  reported  that  the  rewritten  Webserver  ex¬ 
hibited  an  average  throughput  rate  that  was  99.97%  of  the  original 
Webserver’s. 

The  aforementioned  test  is  obviously  not  a  definitive  evaluation 
of  the  feasibility  of  automated  rewriting;  much  work  remains  to 
be  done  in  terms  of  evaluating  the  approach  on  richer  policies  and 
applications.  However,  we  consider  it  to  be  preliminary  evidence 
that  rewriting  can  be  automated  in  a  way  that  produces  acceptable 
annotations. 


6.  Conclusions  and  Future  Work 

Mobile’s  type  system  and  the  theorems  presented  in  §4.4|  show 
that  a  common  style  of  IRM,  in  which  extra  state  variables  and 
guards  that  model  a  security  automaton  have  been  in-lined  into  the 
untrusted  code,  can  be  independently  verified  by  a  type-checker, 
eliminating  the  need  to  bust  the  rewriter  that  produced  the  IRM. 
We  verify  policies  that  are  universally  quantified  over  unbounded 
collections  of  objects — that  is,  policies  that  require  each  object  to 
exhibit  a  history  of  security-relevant  events  that  conforms  to  some 
stated  property.  The  language  of  security  policies  is  left  abstract 
and  could  consist  of  DFA’s,  LTL  expressions,  or  any  computable 
language  of  finite  and  infinite  event  sequences. 

Our  implementation  of  Mobile  for  managed  Microsoft  .NET 
CIL  expresses  security  policies  as  tu-regular  expressions.  We  verify 
such  policies  in  the  presence  of  exceptions,  concurrency,  finalizers, 
and  non-termination,  demonstrating  that  Mobile  can  be  scaled  to 
real  type-safe,  low-level  languages. 

Our  presentation  of  Mobile  has  not  addressed  issues  of  object 
inheritance  of  security-relevant  classes.  Future  work  should  exam¬ 
ine  how  to  safely  express  and  implement  policies  that  require  ob¬ 
jects  related  by  inheritance  to  conform  to  different  properties.  A 
type-checker  for  such  a  system  would  need  to  identify  when  a  type¬ 
cast  at  runtime  could  potentially  lead  to  a  violation  of  the  policy  and 
provide  a  means  for  policy-adherent  programs  to  perform  necessary 
typecasts. 

Another  open  problem  is  how  to  support  a  wider  range  of 
IRM  implementations.  Mobile  supports  only  a  specific  (but  typical) 
treatment  of  runtime  state,  wherein  each  security-relevant  object 
is  paired  with  a  dynamic  representation  of  its  state  every  time  it 
is  leaked  to  the  heap.  In  some  settings,  it  may  be  desirable  to 
implement  IRM’s  that  store  an  object’s  dynamic  state  differently, 
such  as  in  a  separate  array  rather  than  packaged  together  with 
the  object  it  models.  Type  systems  for  coordinated  data  structures 
f26\  could  potentially  be  leveraged  to  enforce  invariants  over  these 
decoupled  objects  and  states. 

We  chose  a  type  system  for  Mobile  that  statically  tracks  con¬ 
trol  flow  in  a  data-insensitive  manner,  with  cu-regular  expressions 
denoting  sets  of  event  sequences.  This  approach  is  appealing  be¬ 
cause  there  is  a  natural  rewriting  strategy  (outlined  in  ^  whereby 
well-typed  Mobile  code  can  be  automatically  generated  from  un¬ 
trusted  CIL  code.  A  more  powerful  type  system  could  employ  a 
richer  language  like  Hoare  Logic  da  to  track  data-sensitive  control 
flow.  This  could  allow  clever  rewriters  to  eliminate  additional  run¬ 
time  checks  by  statically  proving  that  they  are  unnecessary.  How¬ 
ever,  formulating  a  sound  and  complete  Hoare  Logic  for  .NET  that 
includes  objects  and  concurrency  is  challenging;  furthermore,  the 
burden  of  producing  useful  proofs  in  this  logic  would  be  pushed 
to  the  rewriter.  Euture  work  should  investigate  rewriting  strategies 
that  could  make  such  an  approach  worthwhile. 

Einally,  not  every  enforceable  security  policy  can  be  couched 
as  a  computable  property  that  is  universally  quantified  over  object 
instances.  Eor  example,  one  potentially  useful  policy  is  one  that 
requires  that  for  every  file  object  opened  for  writing,  there  exists  an 
encryptor  object  to  which  its  output  stream  has  been  linked.  Such  a 
policy  is  not  supported  by  Mobile  because  it  regards  both  universal 
and  existentially  quantified  properties  that  relate  multiple  object 
instances.  Future  work  should  consider  how  to  implement  IRM’s 
that  enforce  such  policies,  and  how  these  implementations  could 
be  type-checked  so  as  to  statically  verify  that  the  IRM  satisfies  the 
security  policy. 
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Appendix 

The  following  is  a  formal  statement  of  Mobile’s  typing  rules. 


r  h  ldc.i4  n  :  ('I';  fT)  — o  ('J';  TT;  int32) 

Th/i  :  ^3ri.('I'i;fTi;int32) 

r,ri  h/,  :  (v1/i;TTi)  ^3r'. (>!/'; fT';r)  Vi  g  {2,3}  ^^4) 

r  h  /i  /2  h  cond  :  ^  BTi,  ^.(4-';  Tr r) 

r,  r'  h  /i  /2  |o|  cond  :  (T>;  Fr)  -o  3r'.(’T;  fT;  void)  ^^5) 
r,r'  h  h  I2  while  :  ^  3r'.(®;  Tr  ;  void) 

r  h  7i  :  ('i/;Fr)  —o  BF i  .(T^i ;  void) 

r,ri  h  h  :  ^3r2.(T^^7^V)  ^26) 

r  h  7i;/2  :  ^  BTi ,  r2.('T';  Fr r) 

e  e  Dom(^')  field{C,  f)  =  li 
r  h  I  :  (9-,Fr)  ^  3r'.(T'';Fr';C(f))  ^^7) 

r  h  /  Idfld  iiC::f  :  ('I';  Fr)  ^  3r'.(^';  Fr /i) 


r  h  Fi  :  ('I';FT)  ^  3ri.('I'i;FTi;C{F})  £  £  Dom{^') 

r,ri  h/2  :  (’Ti;FTi)  ^3r2.(T'';FT';M)  fieldjC,  f)  =  fi  ^28) 

r  h  Fi  F2  stfld/iC::/  :  (^;Fr)  ^  BTi ,  r2.(^';  Fr void) 


0  <  j  <  n 

r  I-  Idarg  j  :  (ro, .  . .  ,rn))  ^  (T';Fr  (tq,  .  - .  ,rn);rj) 

r  h  7  :  —o  3T' ;Fr' {tq,  . . . ,  Tn);  r)  0  <  j  <  n 

r  h  7  starg  j  :  ('i/\Fr)  — o 

3r'.(^';FT^(ro,...,  r7_i,r,  rj  +  i,...,r„);void) 

h/i :  (i'i_i;FTi_i)_^ 

Vi  e  l..n 

n  =  fields {C)  f  ^  F>om(r,  Fi , . . . ,  r„)  e  £.  pre(policy(C)) 
r  h  Fi  ...  In  newobj  C{pi, . . . ,  p„)  : 

('I'o;FTo)  ^  BFi,. . .  *  (f  1-^  e);FT„;C(f)) 


(29) 

(30) 


(31) 


Fo, .  . .  .Fj  h  Ij  :  ('I'j,Fr7)^3Fj+i.('I'j+i,Frj+i,T7)  Vje0..n 
TO  =  C{£)  £& C::m.Sig& Dom{methodbody) 

Fq,  .  .  .  ,  Fti  F  Sig  <C:  Tn))  ^3Yout'{filout  i  Front  5  T ) 

T^n+l  —  ^unused  m 


Fo  F  Fo  •  ■  •  In  callvirt  Cv.m.Sig  : 

(thojFTo)  — o3Fi, . . . ,  F„  +  1 )  Font  ■  unused  *  ^  out ;  F>:i+l,r) 

(32) 


He  C  pre{policy{C)) 

F  F  F  :  (T>;Fr)  ^  3F'.('I''  *  (F  H)-,Fr';C{l)) 

F  F  F  evt  e  :  ('I';  FT)  — o  EIF'.('I''  *  {£  i-t  He)-,Fr';  void) 
i  0  Dom(r) 

F  F  newpackage  C  :  ('F;  FT)  — o  3F:C(?).('I';  FT ;  C(?)) 

H  C  W  C  policy(C) 

F  F  Fi  :  ('I';Fr)  ^  3Fi .('Fi; Fr  i ;  C{?)) 

F,Fi  FF2  :  (T'i;Fri)  ^  3F2.(®2; Fr  2;  C(F)) 
r,Fi,F2  FF3  :  (^2;Fr2)^3F3.(T''*(Fi-^FF);Fr';gLePf7(g')) 

F  F  Fi  F2  F3  pack  :  ('F;  FT)  —o  EIFi,  F2,  F3.('F';  FT^;  void) 
t  T  Dom{^')  e  0  F)om(F) 

FFF:  (^;FT)  ^3F'.('F';FT'(ro,...,T„);C(?)) 

F  F  F  unpack  j  :  ('F;  Fr  )  ^  3r',£:C,  9. 

(■FTF  1-^  6»;Fr'(ro, . . .  3(ep^{d),Tj+i, .  .  .,Tn)\C{t)) 

FFFi  :  ('F;FT)  ^3Fi.(T-i;FTi;%pp{FF)) 

F,Fi  FF2  :  (rfx+ j^(FF,>Fi);FTi)  ^3F'.('F';FT';t) 
F,Fi  FF3  :  (cto-;^(FF,'Fi);FTi)  ^3F'.('F';FT';t) 

F  F  Fi  F2  F3  condst  k  :  {'I/-,Fr)  ^  3Fi,  F'.(^';  Fr t) 

F  F  Fj  :  (>F,_i;Fri_i)^3Fi.(tFi;Fri;g^ep^XFFi))  Vigl..n 

F  F  Fi  ...  In  newhist  C,k  :  (tFo;  FTq)  — o  3Fi  , .  . . ,  F„. 

Fr„;  HCc,k{lKfPc^{IIi), Ifiep^JHn))) 

Fi,F'FF:  (T'i;Fri)  ^  3F2.(^2;  Fr  2;  r) 
tF'j^  V  tFi  Fr'i  VFTi  'F2r<'F2  Fr  2  di  Fr'2  t  fi,  t' 
Fi,F'FF:  (T'';Fr'i)  ^  BFa,  F'.(^^;  Fr  2;  r') 


(33) 

(34) 

(35) 

(36) 

(37) 

(38) 

(39) 


F  F  §  :  ('F;Fr)  ^ 

{^■,Fr;  void) 

F  F  1^  :  ('F;Fr)  ^ 
^  =  T-'  *  (F 

('F;Fr;int32) 

1-^  FF) 

F,F:CF^ 

:  ('F;Fr) 

-0  {4';Fr;C(£)) 

F,F:C(?}  F 

^  :  ('F;Fr) 

^  ('F;Fr;C(?)) 

F  F 

rep^{H) 

:  (^;Fr)  - 

<.{^-,F?-,lKep  (H)) 

F  F  F  :  (T-;  Fr  )  ^  3F'.(^';  Fr 'Fro;  r) 

F  F  F  ret  :  (-F;  Fr)  -o  3F'.(^';  Fr r) 
Judgment  F  F  Sig^  <:  Sig2  in  rule |32| asserts  that  Sig,^ 
varies  to  Sig2- 


(40) 

(41) 

(42) 

(43) 

(44) 

(45) 
alpha- 


